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(54) Scheme for interlocking a line card to an address recognition engine. 



(57) The present invention provides an interlock 
scheme for use between a line card and an 
address recognition apparatus. The interlock 
schenne reduces the total number of read/write 
operations over a backplane bus coupling the 
line card to the address recognition apparatus 
required to complete a request/response trans- 
fer. Thus, the line card and address recognition 
apparatus are able to perform a large amount of 
request/response transfers with a high level of 
system efficiency. Generally, the interlocking 
scheme according to the present invention 
merges each ownership information storage 
location into the location of the request/res- 
ponse memory utilized to store the correspond- 
ing request/response pair to reduce data 
transfer traffic over the backplane bus. Accord- 
ing to another feature of the interlock scheme 
of the present invention, each of the line card 
and the address recognition engine includes a 
table for storing information relating to a 
plurality of database specifiers. Each of the 
database specifiers contains control infor- 
mation for the traversal of a lookup database 
used by the address recognition apparatus. At 
the time the processor of a line card generates a 
request for the address recognition apparatus, 
it will analyze the protocol type information 
contained in the header of a data packet. The 



processor will utilize the protocol type 
tion as a look-up index to its table of 
specifiers for selection of one of the 
specifiers. The processor will then 1 
identification of the selected database 
into the request with the network 
extracted from the data packet. 
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Field of the Invention 

The present invention is directed to computer net- 
works and, more particularly, to a scheme for Inter- 
locking line cards to a shared address recognition ap- 
paratus utilized for the storage and look-up of net- 
work address information. 

Background of the Invention 

The capability of computers to communicate with 
one another has become a basic attribute of modern 
information processing. There is an ongoing prolifer- 
ation of user applications that depend upon the ability 
of a computer running one of the user applications to 
send and receive data to and from other computers. 
The communication capability is necessary for the 
user application to be able to complete the task for 
which the application was developed or to communi- 
cate information to other users within a group or or- 
ganization. A particular application may be designed, 
for example, to call subroutines running on another 
computer for certain data processing functions or to 
access a remote database to obtain input data or to 
store results. 

An important objective in providing a communica- 
tion capability among computers is to make all of the 
database and processing resources of the group or 
organization available to each user in the group or or- 
ganization. In response to the growing need for so- 
phisticated communication capabilities among com- 
puters, network, routing and bridging protocols such 
as IP, DECnet, OSI, etc. have been developed to con- 
trol data transmissions between computers linked to 
one another in a network. The various protocols are 
implemented in transmission services used to couple 
computers to one another. 

Each protocol is typically defined in terms of a 
number of layers, with each layer relating to a certain 
aspect of the functionality required for data transmis- 
sions throughout a network. For example, the first 
three layers are defined as a physical layer, a data 
link layer and a network layer. The physical layer is di- 
rected to the physical and electrical specifications of 
a physical link, for example, a bus, that couples the 
computers of a network to one another. The physical 
layer controls bit transmissions through the link so 
that a series of bits of a data packet can be commu- 
nicated from one computer on the network to another 
computer on the network. The physical layer will set 
the voltage levels for logical ones and zeros, the tim- 
ing of stable bit information on a physical link and so 
on, as necessary to transmit the bits of a data packet 
over the physical link. 

The data link layer is directed to the packaging or 
framing of bits received in a data transmission into a 
defined packet that is free of transmission errors. The 
data link layer creates and recognizes boundaries be- 



tween bits to define bitfields. The bits between boun- 
daries provide structure and meaning to the bits of a 
data packet. For example the data packet can include 
a header, comprising t he first n bits of a transmission, 

5 for computer source and destination information, the 
length of the data packet in bytes, the network pro- 
tocol being used and so on. The header can be fol- 
lowed by framed bytes of data comprising the actual 
message being communicated between two or more 

10 computers on the network. 

The network layer is directed to the control of 
routing information required to direct a message from 
a source computer to a destination computer of the 
network. Each protocol will define the length and 

IS content for a network address to uniquely identify 
each source or destination of data packets and the 
processing scheme for routing a data packet through 
a network. The network address information is in one 
of the bit fields of a data packet, as framed by the data 

20 link layer processing scheme defined by the protocol. 

Networks are generally arranged into local area 
networks (LANs) and wide area networks (WANs). A 
LAN couples computers that are physically located 
relatively close to one another, as for example in the 

25 same building. A WAN couples computers that may 
be located In different cities or indeed on different 
continents. A WAN usually includes components such 
as a router to receive a data packet from a computer 
on one LAN and to forward the data packet to a com- 

30 puter on another LAN. 

The router processes a network address of a data 
packet according to a protocol implemented in the 
transmission service used on the network to deter- 
mine how the data packet is to be routed, e.g., to an- 

35 other router directly coupled to the receiving LAN or 
to an intermediate router, etc. Each router stores in- 
formation on the topology of the network for use in 
routing each data packet. 

A bridge is another component that may be util- 

40 ized to transfer data packets from computer of one 
LAN to computers of another LAN. A bridge intercou- 
ples different LANs and monitors communications 
within and between the LANs to "learn" source and 
destination address information. The bridge continu- 
es ously learns and "ages" address information to ac- 
commodate the transfer of a data packet between the 
LANs. 

Typically, each of the bridge and router compo- 
nents have access to a look-up database that con- 
so tains bridging or routing information, respectively, re- 
lating to the network addresses of the sources and 
destinations of data in the particular network being 
serviced by the respective router or bridge. An ad- 
dress recognition engine can be implemented as a re- 
55 source for a router or bridge for access to the look-up 
database. 

The router or bridge operates to extract the net- 
work address from the header of a data transmission 
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received at the router or bridge and inputs the ad- 
dress to the address recognition engine. The address 
recognition engine utilizes the input network address 
as an index for traversal of the look-up database to lo- 
cate an entry corresponding to the network address. 
The entry contains protocol information required by 
the router or bridge for directing the data transnnission 
to the designated destination. 

As should be understood, the nature and content 
of the information that would be stored in a database 
entry depends upon whether a router or bridge were 
implemented in the network due to the differing op- 
erating characteristics of routing and bridging opera- 
tions. Moreover, the size and format of the network 
address and the nature and content of the network in- 
formation related to the network address in a partic- 
ular network are defined by the network protocol im- 
plemented in the network. Accordingly, the structure 
of a look-up database must be designed to accommo- 
date either bridging or routing as well as the address 
length and information content requirements of the 
protocol being utilized in the network were the bridge 
or router is operating. Thus, a look-up database de- 
signed to support a router in a network implementing, 
e.g., a DECnet protocol would not be suitable for use 
by a bridge, and so on. 

A problem concerning computer communications 
is encountered when a user application running on a 
computer in a first network utilizing a first data trans- 
mission service needs to communicate with a com- 
puter coupled to another network utilizing a different 
data transmission service. The physical layer imple- 
mented in the first network may be entirely different 
from the corresponding layer implemented in the 
other network. In an effort to fully utilize the process- 
ing and database resources of a computer system, 
more and more user applications running on, for ex- 
ample, computers of a network in one organization 
need to communicate with user applications or proc- 
essing and database resources running on comput- 
ers of a network in a second organization. Each net- 
work and its associated data transmission service 
and network protocol can be viewed as a domain of 
a larger overall network wherein all of the computers 
of the larger network need to communicate with one 
another. 

A series of line cards can be provided to service 
various different data transmission services so as to 
provide a coupling between different domains of a 
computer network. Each line card is dedicated to a 
particular data transmission service and is designed 
to support the physical and data link layers imple- 
mented in the particular data transmission service. 
The line cards are coupled to one another, as, for ex- 
ample, by a backplane bus for transmission of data 
packets across different data transmission services. 

As should be understood, each line card operates 
as a bridge or router and requires a look-up database 



designed to accommodate its needs. While imple- 
menting a look-up database on each line card pro- 
vides a solution to the network address need, such an 
approach results in redundancy of data throughout 
5 the system as well as an inordinate use of line card 
real estate. 

Thus, there is a need for a look-up database that 
is sufficiently flexible in design to function as a shared 
resource to a plurality of line cards and for an efficient 
10 interlock scheme to facilitate high bus traffic between 
the line cards and the shared look-up database re- 
source. 

Summary of the Invention 

15 

The present invention provides an address rec- 
ognition apparatus that is flexible in design and usa- 
ble in routing and bridging operations in the context 
of various different network protocols. In this manner, 
20 a single address recognition apparatus according to 
the present invention can service a router, a bridge or 
both simultaneously, and, at the same time support 
look-up operations for several different protocols. The 
address recognition apparatus is also structured to 
25 accommodate a large amount of network information 
data in an economical and efficient look-up scheme 
so that the address recognition apparatus can ser- 
vice a plurality of routing and bridging components as 
a shared resource. The invention provides a computer 
30 system as defined in claim 1 . 

The present invention also provides a scheme for 
interlocking a series of line cards to the address rec- 
ognition apparatus via a backplane bus. In this man- 
ner, the present invention achieves high speed net- 
35 work address information look-up services with back- 
plane bus efficiency sufficiently high to support a 
backplane based system comprising a plurality of line 
cards and a shared address recognition resource. 
Generally, the address recognition apparatus of 
40 the present invention comprises an address recogni- 
tion engine coupled to a look-up database. The look- 
up database comprises a primary database and a 
secondary database. The address recognition engine 
accepts as an input the network address extracted 
45 from a data transmission. The address recognition en- 
gine uses the network address as an index to the pri- 
mary database. The primary database comprises a 
multiway tree node structure (TRIE) arranged for tra- 
versal of the nodes as a function of preselected seg- 
50 ments of the network address and in a fixed se- 
quence of the segments to locate a pointer to an entry 
in the secondary database. 

The TRIE structure has a predictable search 
time, does not require wide memory for comparisons 
55 of digit values to select a node pointer and can be im- 
plemented in an economical amount of memory 
space particularly in a sparsely populated address 
space, as is often the case in networks. Thus, the 
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TRIE structure for the primary database provides fast 
access to a large amount of data as would be the case 
when the address recognition engine is to be used as 
a shared resource. 

Each segment of the network address used as an 
index by the address recognition engines locates a 
node containing pointers to subsequent nodes, each 
pointer of a particular node being defined by one of 
the possible values of a subsequent segment of the 
address. The traversal of nodes starts at a root node 
and continues through a sequence of transition nodes 
according to the sequence of serpents of the network 
address until a terminal or end node is reached. Each 
terminal node stores the pointer to the secondary da- 
tabase entry corresponding to the network address 
used to reach the terminal node. The entry in the sec- 
ondary database pointed to by the primary database 
pointer contains information necessary for the router 
or bridge, as the case may be, to direct the data trans- 
mission towards its intended destination. 

Each line card is coupled to one or more data 
transmission lines of a particular data transmission 
service. Each line card operates autonomously and 
includes all of the circuitry and logic required to proc- 
ess the physical and data link layers of the particular 
transmission service to transmit and receive data 
packets to and from the respective data transmission 
lines. Each line card includes a processor to perform 
data link and network layer processing for each data 
packet upon reception or for transmission of each 
data packet handled by the line card. 

For each data packet received by a line card, the 
processor extracts the network destination address 
and passes the address as a "request" to the address 
recognition apparatus via the backplane bus. The ad- 
dress recognition engine reads each request and 
uses the address contained in the request as an index 
to the information database for lookup of a corre- 
sponding entry. A portion of the corresponding entry 
is returned to the line interface card as a "response" 
that is then read by the processor The response In- 
cludes the routing or bridging information required by 
the processor of the line card to direct the respective 
data packet to its intended destination. 

In any scheme for transferring requests and re- 
sponses between two devices coupled to one an- 
other by a backplane bus, it is necessary to interlock 
the devices so as to make certain that each request 
is properly identified to the responding device as a 
valid request. In addition, each response must be 
identified to the requesting device as a valid re- 
sponse. The validity of each request and its corre- 
sponding response is typically indicated in "owner- 
ship" information associated with each request, re- 
sponse pair. 

When the ownership information indicates that 
the responding device "owns" a request, this repre- 
sents a request written by a requesting device and yet 



to be processed for a response. Thus, the responding 
device will know that the request is to be used for 
lookup of a corresponding response. When the own- 
ership information indicates that a response is owned 
5 by the requesting device, this represents a response 
returned by the responding device in respect of the 
corresponding request. Accordingly, the requesting 
device will know that the response should be used in 
the processing of the input data relating to that re- 
10 quest. In this manner, requests and responses can be 
efficiently transferred between two devices without 
redundant processing of requests and with a positive 
indication of correspondence between each re- 
sponse and its respective request. 
15 The present invention provides an interlocking 

scheme for the line cards and shared address recog- 
nition apparatus that reduces the total number of 
read/write operations over a backplane bus required 
to complete a request/response transfer. Thus, the 
20 line cards and address recognition apparatus are able 
to perform a large amount of request/response trans- 
fers with a high level of system efficiency. Generally, 
the interlocking scheme according to the present in- 
vention merges each ownership information storage 
25 location into the location of the request/response 
memory utilized to store the corresponding re- 
quest/response pair. In this manner, the requesting 
line cards and responding address recognition appa- 
ratus can read or write the ownership information at 
30 the same time and during the same read/write oper- 
ation used to read or write the respective request/re- 
sponse pair. Accordingly, the overhead imposed 
upon the backplane bus to complete request/re- 
sponse transfers between the line cards and the ad- 
35 dress recognition apparatus is reduced to provide a 
more eff icient operation in the backplane bus system. 

According to another feature of the interlock 
scheme of the present Invention, each of the line 
cards and the address recognition engine includes a 
40 table for storing information relating to a plurality of 
database specifiers. Each of the database specifiers 
contains control Information for the traversal of the 
primary and secondary databases. At the time the 
processor of a line card generates a request for the 
45 address recognition apparatus, it will analyze the pro- 
tocol type information contained in the header of the 
respective data packet 

The processor will utilize the protocol type infor- 
mation as a look-up index to its database specifier ta- 
50 ble for selection of one of the database specifiers. 
The processor will then insert an identification of the 
selected database specifier into the request with the 
network address extracted from the data packet. The 
processor can readily cross reference protocol type 
55 information contained in each data packet to control 
information appropriate for the specific network pro- 
tocol associated with a particular data transmission. 
In this manner, the address recognition engine is in- 
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terlocked to control information for a nnultiple of rout- 
ing and bridging protocols without the need for proc- 
essing protocol type data. 

Thus, the address recognition engine receives as 
a request a network address and an identifier to iden- 
tify one of the database specifiers stored in its table. 
The address recognition engine traverses the prinrtary 
and secondary databases according to the control in- 
formation contained in the database specifier in- 
dexed by the identifier accompanying the network 
address. 

For example, different protocols define different 
address sizes, formats and other information items 
that may be stored in the entries of the secondary da- 
tabase. To accommodate different sizes of network 
addresses according to the formats of different pro- 
tocols; the TRIE of the primary database is arranged 
to have multiple root nodes to provide several traver- 
sal paths, each able to accommodate a different size 
and address format from among the possible network 
addresses that can be input to the address recogni- 
tion engine. Each database specifier includes infor- 
mation on the root node to be used for a particular 
network address. 

The interlock scheme provides an efficient inter- 
lock between several line cards and a shared address 
recognition resource by minimizing the number of 
backplane bus transactions required to complete re- 
quest/response transfers and by implementing a 
streamlined method for exchanging database look-up 
control information between line card processors and 
the shared address recognition apparatus. Thus, an 
integrated backplane bus based system of line cards 
is feasible for coupling different data transmission 
services to one another for computer network inte- 
gration. 

Brief Description of the Drawings 

Fig. 1 is a block diagram of an exemplary comput- 
er network incorporating the interlock scheme of the 
present invention. 

Fig. 2 is a schematic representation of an exem- 
plary embodiment for the physical hardware config- 
uration of the network integration server of Fig. 1. 

Fig. 3 is a block diagram of a high level represen- 
tation of the architecture for a shared memory card 
and line interface cards of the computer network of 
Fig. 1. 

Fig. 4 illustrates a data block structure for the re- 
quest/response RAM of Fig. 3. 

Fig. 5 is a flow diagram for reading and writing 
ownership information in the data block structure of 
Fig 4. 

Fig. 6 is a flow diagram of the operation of the da- 
tabase of Fig. 1. 

Fig. 7 is a flow diagram of the operation of the da- 
tabase during the reading of a request in the re- 



quest/response RAM of Fig. 1. 

Fig. 8 illustrates an example of a network address 
and database specifier input to the address recogni- 
tion engine of Fig. 1 . 
5 Fig. 8A illustrates a data block structure for the re- 

quest/response RAM of Fig. 3. 

Fig. 8B illustrates an example of the database 
specifier field of Fig. 8. 

Fig. 8C illustrates a further data block structure 
10 for the request/response RAM of Fig. 3. 

Fig, 8D is a table of information relating to the 
data block structure of Fig. 8C. 

Fig. 8E illustrates another data block structure for 
the request/response RAM of Fig, 3. 
15 Fig, 8F is a table of information relating to the 

data block structure of Fig. 8E. 

Fig. 8G is a summary of the data structure for the 
data block of Fig. 8E. 

Fig. 9 is a memory map of the memory of the 
20 look-up database of Fig. 1. 

Fig. 10 is a schematic representation of the pri- 
mary database of Fig. 8. 

Fig. 11 illustrates an exemplary structure for a 
prefix string for a node of the primary database of Fig. 
25 10. 

Fig. 12 is a block diagram for a node pointer of 
one of the nodes of the primary database of Fig. 10. 

Fig. 13 illustrates an exemplary format for an en- 
try in the secondary database of Fig. 9. 
30 Fig. 14 illustrates an exemplary format for a look- 

up database specifier of the address recognition en- 
gine of Fig. 1. 

Detailed Description 

35 

Referring now to the drawings, and initially to Fig. 
1 , there is illustrated, in block diagram form, an exam- 
ple of a computer network generally indicated by the 
reference numeral 10. The network 10 comprises a 

40 plurality of local area networks (LANs) including an 
802.5 token ring LAN 12 and two 802.3 LANs 14, 16. 
The 802.5 LAN 12 comprises a plurality of personal 
computers 18, all coupled to one another by a token 
ring bus 20 for communication among the personal 

45 computers 18 within the LAN 12. A token ring router 
22 is also coupled to the bus 20 and is further coupled 
to a wide area network (WAN) router 500 24 by an 
802.3 bus 26 so that the personal computers 1 8 of the 
LAN 12 can communicate with other devices outside 

50 the LAN 1 2 via the token ring router 22 and WAN rout- 
er 24. To that end, the WAN router 24 is coupled to a 
T1 data transmission line 28 for communication with, 
e.g., a personal computer of another LAN 14, 16, as 
will appear. 

55 The 802.3 LAN 14 also comprises a plurality of 

personal computers 30 coupled to one another for 
communication within the LAN 14 by an 802.3 LAN 
bus 32. A WAN router 100 34 is coupled to the bus 32 
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and to an X.25 data transmission line 36 for transmis- 
sion of data from any one of the persona! computers 
30 to outside the LAN 14. In a similar manner, the 
802.3 LAN 16 comprises a plurality of personal com- 
puters 38 coupled to one another and to a Translan 
320 bridge 40 by an 802.3 LAN bus 42. The bridge 40 
is coupled to a Transpath 350 bridge 44 by a 64K bps 
data transmission line 46. The bridge 44 Is further 
coupled to a T1 data transmission line 48 for bridging 
data between LANs. 

Moreover, each of a plurality of personal comput- 
ers 50 is coupled to a WAN router 250 54 of the net- 
work 10 by a point-to-point coupling 52. Each point- 
to-point coupling 52 may comprise a sync, async or 
dial 1200-19200 bps data transmission service. The 
WAN router 54 is, in turn, coupled to a WAN router 500 
56 by a 64K bps data transmission line 58 and the 
router 56 is further coupled to an 802.3 LAN bus 60. 

As should be understood from the above, a data 
transmission from any one of the computers 18 of the 
LAN 12 will be transmitted out of the LAN 12 via the 
router 22, 802.3 LAN bus 26 and router 24 onto a T1 
transmission line, while data transmissions from any 
one of the computers 30, 38, 50 are ultimately routed 
out of their respective local operating environments 
via X.25, T1 and 802.3 LAN transmission services, re- 
spectively. In addition, the personal computers 38 of 
the LAN 16 utilize a bridge for communication with 
personal computers of other LANs while the personal 
computers 18, 30, and 50 are coupled to routers. Ac- 
cordingly, if a user application such as electronic mail 
were running on each of the computers 1 8, 30, 38 and 
50, it is necessary to provide a multi- protocol routing 
and bridging service in the network 10 so that a mail 
message from, e.g., one of the computers 18 of the 
LAN 12 can be transmitted via the T1 transmission 
service and received through the 802.3 LAN service 
by, e.g., one of the computers 50. 

To that end, a network integration server 62 is 
coupled to each of the transmission lines 28, 36, 48 
and 60 to receive data transmissions, typically in the 
form of data packets, from any one of the transmis- 
sion lines 28, 36, 48 and 60 and to route or bridge 
each data packet out on any one of the transmission 
lines 28, 36, 48 and 60. The network integration ser- 
ver 62 provides, in a single device, network connec- 
tivity between any number of different user applica- 
tions running on the various computers 1 8, 30, 38 and 
50 by providing a mapping scheme between the user 
application services available on the constituent com- 
puters 18, 30, 38 and 50 of the network 10 and the 
multiplicity of transmission services that may be used 
throughout the network 10. In this manner, a mail 
message, e.g., received from one of the computers 18 
over the T1 transmission line 28 can be routed by the 
network integration server 62 to one of the computers 
50 via the 802.3 LAN 60, router 56, 64K bps line 58, 
router 54 and point-to-point coupling 52. 



Referring to Fig. 2, there is illustrated schemati- 
cally an exemplary embodiment for the physical hard- 
ware configuration of the network integration server 
62. A standard 19" rack 64 having a backplane bus 

5 (not illustrated here, see Fig. 3) is arranged with slots, 
in a known manner, to slidably receive and mount cir- 
cuit cards 66. The rack 64 can include nine slots. The 
circuit cards 66 include a power card 68 physically re- 
ceived into two of the slots to provide a power source 

10 to each of the cards 66 operating in the server 62, a 
management card 70 received into one of the slots for 
initialization, control and management of the operat- 
ing cards 66 including input and update of routing in- 
formation relevant to the network, a memory card 72 

15 received into another of the slots for centralized 
shared memory services, as wilt be explained in more 
detail below, and a series of line interface cards 74, 
each received into one of the remaining seven slots 
oftherack64. 

20 Each line interface card 74 operates autono- 

mously and includes all of the circuitry and logic re- 
quired to process the physical and data link layers of 
a particular transmission service protocol, e.g. one of 
the T1 and X.25 transmission services. In addition, 
25 each line interface card 74 includes a network layer 
processor for the network protocols supported by the 
respective line interface card 74. The shared memory 
card 72 provides centralized network routing and 
bridging information services to the network layer 
30 processors of the line interface cards 74. Each line in- 
terface card 74 can communicate with any one of the 
other line interface cards 74 via the backplane bus to 
affect the transfer of each data packet received at the 
respective line interface card 74 according to the net- 
35 work routing or bridging information obtained from 
the shared memory card 72, to one of the other line 
interface cards 74 for transmission out of the network 
integration server 62. 

Each line interface card 74 is provided with a port 
40 or ports for physical and electrical connection to a 
transmission line operating according to the transmis- 
sion service supported by the respective line inter- 
face card 74. For example, line interface card 74Acan 
support a low speed synchronous transmission ser- 
45 vice through a modem and is provided with a 50 pin 
port 76 on a front panel for coupling with a 50 wire 
cable 78. The 50 pin port-50 wire cable arrangement 
76, 78 is used for a fan out of lines required to service 
eight modem connections. The cable 78 is coupled to 
50 a remote distribution panel 80 mounted to the rack 64 
below the slots used to mount and support the cards 
66. The remote distribution panel includes eight ports 
82 for coupling to eight different modems (not illustrat- 
ed). The remaining cards 74 are each provided with 
55 appropriate ports 84, 86 on the respective front panel 
for coupling directly to transmission rtne(s) operating 
according to the transmission service supported by 
the respective line interface card 74. 
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The rack and slot configuration for the physical 
hardware support structure provides a modular de- 
sign for flexibility and expandability. The network in- 
tegration server 62 can be rearranged to handle ad- 
ditional or different transmission services sinnply by 5 
adding or replacing tine interface cards 74 as required 
by the various types of transmission services used in 
a particular network. In addition, the autonomous 
performance of all the physical and data link process- 
ing on each line interface card for the transmission io 
service supported by the line interface card, results 
in a high performance data transmission capacity 
that can be increased incrementally by adding lino in- 
terface cards 74 to the rack 64 as data traffic on the 
network increases. ^5 

Fig. 3 shows, in block diagram form, a high level 
representation of the architecture for the shared 
memory card 72 and line interface cards 74A, 74B of 
the network integration server 62. The network inte- 
gration server 62 is a backplane based system used 20 
to provide network connectivity among dissimilar 
data transmission services. Fig. 3 illustrates two line 
interface cards 74A and 74B. The line interface card 
74A supports a low speed synchronous transmission 
service such as a 64K bps service, while line inter- 25 
face card 74B supports a T1 transmission service. It 
should be understood that the specific transmission 
services described in respect of the line interface 
cards 74A, 748 are representative as a line interface 
card for any particular transmission service can be 30 
provided on the netvyork integration server 62, as re- 
quired by the network. 

Generally, each line interface card 74A, 748 
comprises a line interface 88A, 888 coupled to the re- 
spective transmission line 60, 28, a processor 90A, 35 
908 for data link processing, network layer routing 
and bridging processing and management transac- 
tions and a backplane bus interface 92A, 928, re- 
spectively. Each processor 90A, 908 is coupled to a 
table 93A, 938, respectively, for storage of identifiers 40 
for database specifiers, as will be described below. 
The memory card 72 comprises an address recogni- 
tion engine 96A and request/response RAM 968 for 
centralized routing and bridging information services 
available to the line interface cards 74A, 748, a look- 45 
up database 94, a table 94A and a backplane bus in- 
terface 98. 

A high performance asynchronous backplane 
bus 1 5 is coupled to each of the memory card 72 and 
line interface cards 74A, 748 via the respective back- 50 
plane bus interfaces 92A, 928, 98. The backplane 
bus 15 operates according to the Futurebus IEEE 
Backplane Bus Specification (ANSE/IEEE Std 896.1) 
to provide communication services between the line 
interface cards 74A, 74B and the memory card 72. 55 

Each line interface 88A, 888 provides the physi- 
cal and electrical connectivity to the respective data 
transmission line 60, 28 for bit transmission. For ex- 



ample, each line interface 88A, 88B is coupled by a 
distribution panel or adapter cable to an RS232, 
RS422/449, V.35 or X.21 leased telephone line and is 
adapted to transmit and receive serial bits of a data 
packet according to the electrical and physical spec- 
ification of the leased line. In addition, each line inter- 
face 88A, 888 formats the serially transmitted bits 
into data packets according to the data link protocol 
utilized in the respective transmission service, as for 
example one of the standard HDLC, LAPB or PPP 
data links. 

Each processor 90A, 908 performs the data link 
and network layer routing or bridging processing re- 
quired upon reception or for transmission of each data 
packet by the respective line interface 88A, 88B. The 
network layer processing is performed by the proc- 
essor 90A, 908 according to the network layer proto- 
col utilized in the domain coupled to the respective 
transmission service, as for example, one of the OSI, 
IP and DECnet net-work protocols, the IS-IS multi- 
protocol routing scheme and/or a bridging protocol. 
The processor 90A, 90B analyzes the format of each 
data packet to determine the network layer protocol 
do be used for that data packet. 

The memory card 72 provides centralized data- 
base services for all of the line interface cards 74 in 
the network integration server 62. These services in- 
clude the address recognition engine 96A which is 
coupled to each of the information look-up database 
94 and the table 94Afor storage of database specifi- 
ers, is will appear. For each data packet received by 
a line interface card 74A, 748, the processor 90A, 
90B extracts the network destination address and 
passes the address as a "request" to the request/re- 
sponse RAM 968 via the bus 15. The address recog- 
nition engine 96A reads each request in the re- 
quest/response RAM 968 and uses the address con- 
tained in the request as an index to the routing infor- 
mation database for lookup of a corresponding entry. 
A portion of the corresponding entry is placed in the 
request/response RAM 968 as a "response" that is 
then read by the processor 90A, 908 again via the 
bus 15. The response includes routing information 
that indicates which line interface card 74 of the net- 
work integration server 62 is to get the data packet 
corresponding to the request/response for transmis- 
sion out of the network integration server 62, The re- 
quests and responses are communicated between 
the line interface cards 74 and the address recogni- 
tion engine 96A through a device interlocking scheme 
feature of the present invention that is implemented 
in the request/response RAM 96B, as will be descri- 
bed in more detail below. 

Referring now to Fig. 4, there is illustrated in 
more detail a data block structure for the request/re- 
sponse RAM 968. The request/response RAM 96B 
provides an interlock mechanism between each proc- 
essor 90A, 908 and the address recognition engine 
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96A for an exchange of request and response infor- 
mation. The request/response RAM 96B is divided 
into a plurality of rings 100, e.g. 32 rings, with each 
ring 100 being dedicated to one of the processors 
90A, SOB. Each of the processors 90A, 908 may have 
one or more rings allocated to It depending on the 
data traffic expected through the processor 90A, 908 
so as to properly balance the servicing of requests by 
the address recognition engine 96A. For example, the 
processor 90A may have more allocated rings 100 
than the processor 908. Each ring 100 is further div- 
ided into a plurality of entries 101, as for example, 16 
entries 101 per ring 100. 

As illustrated In Fig 4, each entry 101 has suffi- 
cient memory space to store 16 longwords 102, des- 
ignated as 0 to 1 5 in each entry 101. Af irst set of eight 
longwords, 0-7, of each entry 101 is used to store a 
request. A second set of eight longwords, 8-15, of 
each entry 1 01 is used by the address recognition en- 
gine 96A to store the response corresponding to the 
request stored in longwords 0-7 of the respective en- 
try 101. 

Each processor 90A, 908 maintains a pointer 
mechanism including a first pointer to indicate the lo- 
cation of a next entry 101 in one of its rings 100 in the 
request/response RAM 968 that is available to store 
a request The first pointer will increment to a next lo- 
cation after each request is stored in the request/re- 
sponse RAM 968. In addition, a second pointer of the 
pointer mechanism indicates the location of a previ- 
ously used entry 101 that should be accessed for 
reading of a response. The second pointer is also in- 
cremented after the processor 90A, 908 reads the re- 
sponse 

The first and second pointers are initialized to 
point to the same entry location and will each contin- 
uously loop around the ring or rings allocated to the 
respective processor 90A, 908 as they are increment- 
ed. If the first pointer loops around the ring 100 faster 
than the rate at which the processor 90A, 908 reads 
responses from the request/response RAM 968, (i.e., 
faster than the address recognition engine 96A can 
service requests) the location pointed to by the first 
pointer will eventually coincide with the location point- 
ed to by the second pointer. At that time, the proces- 
sor 90A, 908 will stop sending requests to the re- 
quest/response RAM 968 until the second pointer 
has been incremented to point to another entry in the 
ring 100. 

The address recognition engine 96A polls each 
ring lOOof the request/response RAM 968 on a round 
robin basis, for requests to service. The address rec- 
ognition engine 96A reads one entry 101 of each ring 
100 as it polls each ring 100 and continues polling to 
eventually read all of the entries 101. 

During the exchange of requests and responses 
between the processors 90A, 908 and the address 
recognition engine 96A, it is necessary to communi- 



cate the validity of a request or a response in a par- 
ticular entry 101 to the address recognition engine 
96A or processor 90A, 908, respectively. In other 
words, the address recognition engine 96A must be 
5 able to determine whether a request in an entry 101 
that it polls is one that should be serviced (valid) or 
one that has already been serviced and thus should 
not be read (invalid). Similarly, a processor 90A, 908 
must be able to determine whether a response in an 

10 entry 101 is the response to the request that it last 
stored in the entry 1 01 (valid) or a stale response cor- 
responding to a previous request (invalid). 

Pursuant to a feature of the present invention, the 
interlock between the processors 90A, 908 and the 

15 address recognition engine 96A provides for "owner- 
ship" information to be stored in dedicated bytes of 
each request and each response memory space of 
each entry 101 as an indication of the validity of the 
data in the respective memory space of the entry 

20 101. Moreover, the setting and clearing of the owner- 
ship information is performed by both the processors 
90A, 908 and the address recognition engine 96A 
during their respective read and write operations in re- 
spect of requests and responses to minimize the total 

25 number of bus transactions required to complete the 
request/response transfer. This minimizes the bus 
transaction overhead for the transfer of a request/re- 
sponse pair through the computer system 10 and, 
therefore, further facilitates the prompt completion of 

30 the bus transactions required for the return of re- 
sponses to the processors 90A, 908. 

Referring once again to Fig. 4, the first byte 103 
of the first set of longwords 102 (longwords 0-7 of 
each entry 101 for storage of a request) is dedicated 

35 to store an OWNJD bit 104 and a REQJD bit 105. In 
addition, the first byte 106 of the second set of long- 
words 102 (longwords 8-15 of each entry for storage 
of a response) is dedicated to store a RSP_ID bit 107. 
The OWNJD. REQJD and RSPJD bits 104, 105, 

40 1 07 together provide the ownership information nec- 
essary for an indication of the validity of data stored 
in the respective entry 101 . Moreover, the storage of 
the OWNJD and REQJD and RSP_ID bits at the re- 
quest and the response memory spaces of each en- 

45 try 101, respectively, allows for the reading and 
changing of ownership information within the same 
read/ write operations for the respective request /re- 
sponse pair, as will appear. 

Referring now to Fig. 5, there is illustrated a flow 

50 diagram for the reading and changing of ownership in- 
formation by the processors 90A, 908 and the ad- 
dress recognition engine 96A during their respective 
read and write operations in a request/response 
transfer for validation and verification of validation of 

55 the request and response data stored in a respective 
entry 101 of a ring 100. At initialization of the system, 
the OWNJD bit 104 is negated and each of the 
REQ ID bit 105 and RSPJD bit 107 is asserted. In 
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Fig. 5, the asserted state for each bit is indicated by 
a logical 1 and the negated state is indicated by a log- 
ical 0. 

When a processor 90A, 90B sends a request over 
the bus 15 to the request/response RAM 96B. the 
processor 90A, 90B will address the request to long- 
words 0-7 of the entry 101 currently pointed to by the 
first pointer and include a first byte in the request that 
asserts the OWNJD bit 104 and negates the 
REQJD bit 1 05. The location of the first pointer rela- 
tive to the second pointer will verify that the entry 101 
is available. When the address is stable on the bus 
1 5, the address recognition engine 96A will recognize 
a request/response RAM address and pass the re- 
quest directly to the request/response RAM 968 over 
the coupling 24 between the request/response RAM 
968 and the address recognition engine 96A, as illu- 
strated in Fig. 3. 

The request will be written into the location of 
longwords 0-7 of the addressed entry 101 in the re- 
quest/response RAM 968, including the first byte that 
asserts the OWNJD bit 104 and negates the 
REQJD bit 105 (see 108, 109). At this tinne, the ad- 
dress recognition engine 96Aowns the entry 101 (in- 
dicated by the asserted OWNJD bit 104) and the re- 
sponse currently in the entry 101 is invalid (indicated 
by the misnnatch between the now negated REQJD 
bit 105 and the asserted RSPJD bit 107). The proc- 
essor 90A, 908 will follow the convention of asserting 
the OWNJD bit and negating the REQJD bit during 
the first and every alternate traversal of the respec- 
tive ring 100 when writing requests to the request/re- 
sponse RAM 968. 

During the polling operation, the address recog- 
nition engine 96A will eventually read the request in 
the entry 101 . The asserted OWNJD bit 1 04 tells the 
address recognition engine 96A that it owns the re- 
quest (see 109). In order to pernnit the writing of re- 
quests that vary in length, each of the OWNJD bit 
104 and REQJD bit 105 is written into the first byte 
of the first longword 102 of the entry 101 so that a 
fixed convention for a validity indication can be fol- 
lowed despite the variable length of the request. The 
processor 90A, 908 will, therefore, write the owner- 
ship information at the beginning of a write operation 
and then continue to write the request. The address 
recognition engine 96A must be able to determine 
that the OWNJD bit 104 in the first longword 102 is 
associated with a request that has been completely 
written into the respective entry 101 (i.e., the proces- 
sor 90A, 90B has completed its write operation to the 
request/response RAM 968). 

Referring now to Fig. 6, there is illustrated a flow 
diagram for a portion of the hardware operation of the 
address recognition engine 96A utilized to make cer- 
tain that the write operation for a request associated 
with an asserted OWNJD bit 104 has been complet- 
ed. The address recognition engine 96A is arranged 



to assert an REQ_WIP signal whenever a write to the 
request/response RAM 968 through the bus 15 is in 
progress. In step 200 of the operation of the address 
recognition engine 96A, the address recognition en- 
5 gine 96A initially assumes that the bus 15 Is idle. In 
step 201, the address recognition engine 96A moni- 
tors the bus 15 to determine whether the AS* signal 
of the Futurebus asynchronous bus protocol is as- 
serted on the bus 1 5, the processor 90A, 908 has as- 
10 serted a command for a write operation and the ad- 
dress placed on the bus 15 during the connection 
phase is for the request/response RAM 968. 

If this determination is negative, the operation of 
the address recognition engine 96A loops back to 
15 step 200. However, if this determination is positive, 
the address recognition engine 96A asserts the 
REQ_W1P signal in step 202. The address recognition 
engine 96A will continue to monitor the bus 15 until 
the AS* signal is negated (step 203). Prior to the neg- 
20 ation of the AS* signal, the address recognition en- 
gine 96A loops back to step 202 and continues to as- 
sert the REQ_WIP signal. Upon the negation of the 
AS* signal by the processor 90A, 908, to Indicate the 
disconnection phase of the respective bus transac- 
25 tlon, the address recognition engine 96A loops back 
to step 200 and negates the REQ_WIP signal. Thus, 
the operation of the address recognition engine 96A, 
as Illustrated in Fig. 6, provides a positive indication 
(the REQ_WIP signal) whenever a write operation to 
30 the request/response RAM 968 is in progress. 

Referring now to Fig. 7, there Is Illustrated a flow 
diagram for the operation of the address recognition 
engine 96A during the reading of a request. In step 
300, the address recognition engine 96A reads long- 
35 word Oofthe entry 101 Including the OWNJD bit 104. 
In step 301 , the address recognition engine 96A de- 
termines whether the OWNJD bit 104 is asserted. If 
It Is not asserted, the address recognition engine 96A 
continues the polling process to a next ring 100 (step 
40 302). However, if the OWNJD bit 104 is set, as in the 
example Illustrated at 109 of Fig. 7, the address rec- 
ognition engine 96A determines whether the REQ 
wIP signal is also asserted to Indicate that a write of 
a request to the request/response RAM 968 is In pro- 
45 gress (step 303). 

If the REQ_W1P signal Is not asserted, the ad- 
dress recognition engine 96A continues to process 
the request and then moves on to a next ring 100, ac- 
cording to the polling scheme (steps 304, 305). 
50 Referring back to Fig. 5, the address recognition 

engine 96Awni relinquish ownership of the entry 101 
upon reading a valid request by writing a negated 
OWNJD bit 104 to the first byte of longword 0, 112. 
113. After the address recognition engine 96Aservic- 
55 es a request, it writes the corresponding response 
into longwords 8-15 of the entry 101 as indicated at 
110. The first byte of the response, in longword 8, in- 
cludes an RSPJD bit 107 that matches the RSPJD 

10 
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bit 107 written by the processor 90A, 90B when it 
wrote the request to longwords 0-7 of the entry 101 , 
as described above. In this instance, the RSPJD bit 
107 is negated as shown at 111. 

The address recognition engine 96Annust there- 
fore access the request/response RAM 96B three 
times during the servicing of each request, once to 
read the request, once to negate the OWNJD bit 1 04 
and once to write the response, including the RSP__ID 
bit. However, due to the point-to-point coupling 24 be- 
tween the address recognition engine 96Aand the re- 
quest/response RAM 96B, there is no overhead on 
the bus 15. 

The processor 90A, 908 accesses the entry 101 
during a subsequent bus transaction when the sec- 
ond pointer points to the entry 101. At that time, the 
processor accesses and reads longwords 8-1 5 of the 
entry 101 for the response and the RSPJD bit 107. 
The processor 90A, 908 will know that the response 
is valid when the RSPJD bit 107 written by the ad- 
dress recognition engine 96A matches the REQJD 
bit written by the processor 90A, 908 when it wrote 
the request As shown at 109 and 111, the processor 
90A, 908 negated the REQJD bit 105 when writing 
the request and the address recognition engine 96A 
negated the RSPJD bit 107 when writing the re- 
sponse. If the REQJD bit does not match the RSPJD 
bit, the response is not valid (i.e. the address recog- 
nition engine 96A has not yet serviced the request) 
and the processor 90A, 908 must read the response 
again at a later time. 

In this manner, the processor 90A, 908 is able to 
complete the request/response transfer in two bus 
transactions over the bus 15. During the write opera- 
tion for t he request, the processor 90A, 908 need only 
access the request longwords 0-7 of the entry to write 
the ownership information in the OWNJD bit 1 04 and 
the REQJD bit 105. During the read operation for the 
response, the processor 90A, 90B need only access 
the response longwords 8-15 of the entry to deter- 
mine the validity of the response through a match be- 
tween the REQJD bit 105 that it wrote during the 
write request operation and the matching RSP_ID bit 
107 that the processor 90A, 90B reads during the 
second bus transaction. 

As is the case with requests, each response can 
beof variable length. Thus, the RSPJD bit 1 07 is also 
written into the first byte of the first longword 102 so 
that a fixed convention for a validity indication can be 
followed despite the variable length of the response. 
The address recognition engine 96A operates to hold 
any read for a response if it Is currently writing the re- 
sponse to the address indicated in the read. This will 
insure that RSPJD bit 107 in the first longword 102 
of the response is associated with a response that 
has been completely written by the address recogni- 
tion engine 96A. 

For a second and every alternate traversal of the 



ring 100 by the processor 90A, 908, the first byte 103 
written by the processor 90A, 908 (114) asserts each 
of the OWNJD bit 104 and the REQJD bit 105, as 
shown at 115. The REQJD bit 105 is asserted in the 

5 second and each alternate traversal of the ring 100 to 
again cause a mismatch between the REQJD bit 105 
and the RSPJD bit 1 07 since the address recognition 
engine 96A negates the RSPJD bit 1 07 during the re- 
sponse write operation of the first and each alternate 

10 traversal of the ring 100. The write response, relin- 
quish ownership and read response operations 116, 
117 for the second and each alternate traversal is 
similar to the operations for the first and each alter- 
nate traversal ofthering 100, except that the address 

15 recognition engine 96A now asserts the RSPJD bit 
107 when writing a response, to provide a match with 
the asserted REQJD bit 105, as shown at 118. 

Referring again to Fig. 7, if, during a request read 
operation by the address recognition engine 96A, the 

20 REQ_WIP signal is asserted 303, the address recog- 
nition engine 96A compares the address of longword 
0 of the entry being accessed for a request read op- 
eration with the address of the entry on the bus 15 
for which a request write operation is in progress 

25 (305). If there is a mismatch, the address recognition 
engine 96A proceeds to process the request (304). 
However, if there is a match, the address recognition 
engine 96A waits for the write operation to complete, 
i.e. a negation of the REQ_WIP signal (306). There- 

30 after, the address recognition engine 96A proceeds to 
process the request (304). 

An example of a request 403 is shown in Fig. 8. 
The request 403 comprises an N bit network address 
403A, for example, a 16 bit address, and a database 

35 specifier index field 4038. The format for each re- 
quest 403 and the structure for the entries 1 01 of the 
request/response RAM 968 permit a programmable 
request/response setup. 

For example, referring to Fig. 8A, there is illustrat- 

40 ed an encoded stream of N requests that are concat- 
enated and written Into the request portion of a single 
entry 101. The handshake byte comprises the 
OWNJD 104 and REQJD 105 bits of the request/re- 
sponse interlock described above. A series of N re- 

45 quests are then written with the OWNJD and 
REQJD information to an entry 101 of the re- 
quest/response RAM 968 with a "terminator" request 
ending the byte stream of the concatenated byte 
stream. 

50 Moreover, each request can be one of several 

types formatted as either a type-value or type- 
length-value encoded byte stream, as will be descri- 
bed. 

The request/response entry example of Fig. 4 
55 represents a type-vatue encoded stream with a total 
fixed length of 16 longwords for the request and re- 
sponse. The example of Fig. 4 is a parser type request 
that is used in a regular look-up operation of the ad- 
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dress recognition engine 96A. 

Fig. 8B illustrates an example of the database 
specifier index field 403B fornnatted to indicate both 
a database specifier index and a request type. A first 
five bit value, for example, is used to identify a par- 
ticular database specif ier for control of the look-up op- 
eration, as will appear. Asecond set of two bits is used 
to identify a request type. In addition to the parser 
type request, there can be, for example, an interroga- 
tive type request and a maintenance type request. 

The interrogative type request is used to return, 
in a response, information on the look-up operation of 
the address recognition engine, for example, when a 
match for a network address is not found in the look- 
up. Fig. 8C illustrates the structure for the request/re- 
sponse entry 101 when formatted for an interrogative 
type request and the table of Fig. 8D shows the infor- 
mation contained in a response to an interrogative re- 
quest. The TRA and TER designations in the table of 
Fig. 8D refer to transition and termination nodes of the 
look-up database, as will be described below in the 
detailed description of the database 94. The response 
information indicates details of the traversal of the da- 
tabase 94 and where the search ended. 

The maintenance type request can be either a 
read or write operation and enables a direct memory 
access operation (DMA) to the database 94. This type 
of request can be used to read or write blocks of the 
database 94 to maintain the information of the data- 
base. Fig. 8E illustrates the structure for the re- 
quest/response entry 101 when formatted for a main- 
tenance type request. Fig. 8F is a table showing con- 
trol parameters for a DMA operation using the re- 
quest/response interlock and Fig. 8G is a summary of 
a request/response entry 101 in a maintenance DMA 
operation. Thus, preselected blocks of the database 
are readily accessible to review information stored in 
the database 94 (read DMA) or to write new or updat- 
ed information directly into the database (write DMA). 

As illustrated in Figs. 8C and 8E, the request/re- 
sponse entry 101 is expanded to a 128 longword 
space to accomodate longer interrogative and DMA 
responses. The request type field of the database 
specifier index 403B provides increased flexibility in 
the operation of the address recognition engine 94A 
for maintaining and monitoring the database 94. 

Referring now to Fig. 9, there is illustrated a 
memory map for the look-up database 94 of the ad- 
dress recognition engine 96A. As described above, 
the address recognition engine 96A uses a network 
address that is stored in the request portion of an en- 
try in the request/response RAM 968 as an index to 
the database 94 to locate an entry in the database 94. 
The entry in the database 94 contains the network in- 
formation relating to the network address that is re- 
turned by the address recognition engine 96Ato the 
request/response RAM 968 as a response. The proc- 
essor 90A, 908 in the line card 74A, 748 utilizes the 



response to process the network information for 
transmission of the data packet to its intended destin- 
ation. 

The database 94 is divided into a primary data- 

5 base 401 and a secondary database 402. The pri- 
mary database 401 comprises a multiway tree data 
structure (TRIE), as wilLbe described below, wherein 
the network address is used to locate a pointer to an 
entry in the secondary database 402. The entry in the 

10 secondary database 402 includes the network infor- 
mation for the response. 

As described above the address recognition en- 
gine 96A maintains the table 94A as a look-up table 
for database specifiers used in the control of a iook- 

15 up operation in the look-up database 94, as will be de- 
scribed below. The index field 4038 in the request in- 
put to the address recognition engine 96A provides an 
index to the table 94A to locate a look-up database 
specif ier that is to be used in a current response look- 

20 up. Each processor 90A, 908, at the time of extracting 
a network address from a data packet for a request, 
also utilizes the protocol type information in the head- 
er of the data packet to select an identifier for a data- 
base specifier from the table 93A, 93B. The proces- 

25 sor 90A, 908 places the identifier for the database 
specifier in the index field 4038 of the respective re- 
quest 403. 

The address recognition engine 96A reads the 
address 403Afrom the request and processes the ad- 

30 dress 403A in groups of four bits. Each group of four 
bits is referred to as a digit 404. The primary database 
401 comprises a plurality of nodes 405 linked to one 
another by node pointers 406 with each node 405 be- 
ing associated with a particular value for a digit or se- 

35 quence of digits of a network address. Generally, 
each node 405 comprises 16 node pointer entries 
406, one for each unique bit combination value of a 
four bit digit 404 that follows in sequence the digit or 
sequence of digits associated -with the respective 

40 node 405 (2^ equals 16, 0000 to 1111), as shown in 
Fig. 10. 

The address recognition engine 96Awill first ac- 
cess the primary database 401 using a root pointer 
address 408 that points to the root node 405Aof the 

45 primary database 401. the root pointer address is 
identified in the database specifier being used by the 
address recognition engine 96A, as will appear. The 
root node 405A includes 16 node pointers 407, each 
including, for example, the address of one of the 

50 nodes associated with digits having the four highest 
order network address bits equal to 0000 to 1111, re- 
spectively. The address recognition engine 96A will 
utilize the node pointer 407 associated with the value 
of the bits of the first digit 404 that matches the value 

55 of the first digit of the network address being proc- 
essed, for example bits of the first digit equal to 0000, 
to access the next node. 

In the example of Fig. 10, the node 405 associ- 
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ated with the digit 404 including bits 0-3 equal to 0000 
has 16 node pointers 407, including a node pointer 
407 that Is an address to a further node 405 associ- 
ated with one of the valves of the combination of bits 
for the next digit 404 of the network address, wherein 
the bits of the next digit equal 0000 and so on. 

The primary database 401 is constructed in this 
manner so that each possible value for a digit 404 
(e.g. the digit comprising bits 0-3) is linked to every 
possible digit value in the sequence of digits 404 that 
can comprise a network address (e.g. the digits com- 
prising bits 4-7, 3-11 and 12-15) through the 16 node 
pointers 407 in each node 405. The address recogni- 
tion engine 98A will traverse the primary database 
401 from node to node via the node pointers 407 for 
the digit values that match the corresnonding digit 
values of the network address being processed until 
all of the digits have been matched. 

Each node 405 that points to a next node 405 in 
the sequence of digits of the network address is 
called a transition node (i.e. a node that points to an- 
other node). The nodes associated with the digits 
comprising the lowest four order bits of a network ad- 
dress are called termination nodes 405B since a 
match with the bits of the last digit completes the 
match process for the 16 bit network address of this 
example. Each termination node 405B comprises 16 
look-up match pointers 409, one for each of the 16 
possible values for the digit 404 comprising bits 12- 
15. Each look-up match pointer 409 comprises an ad- 
dress to an entry in the secondary database 402. 

In view of the sparsely populated address spaces 
frequently encountered in networks, the nodes 405 
are provided with prefix strings 410 to reduce the 
amountof memory space required for the primary da- 
tabase 401 and to decrease the search tine. Asparse- 
ly populated space means that only a relatively few of 
the total numberof bit valves that can be represented 
by an n bit net-work address actually form an address 
for a component in the network. A prefix string is a 
string of digits that is common to many addresses. As 
should be understood, there may be a large number 
of common digits in a sparsely populated address 
space. 

For example, a 16 bit network address can 
uniquely identify over 65,000 network components. 
However, the network utilizing the 16 bit address may 
only have 16 components, each of which can be 
uniquely identified by one of the 16 possible values 
of the lowest order digit of the address. This in an ex- 
ample of a sparsely populated address space and the 
values of the three higher order digits for all of the 1 6 
components may be the same. 

Thus, in this example, a prefix string can com- 
prise a string of the three higher order digits used for 
a comparison to the three higher order digits of a net- 
work address being processed in a single node 405. 
The use of prefix strings will minimize the total mem- 



ory space required to implement the primary data- 
base 401 since fewer total nodes 405 will be required 
to search a particular network address. The address 
recognition engine 96A will compare three digits of an 

5 address in the node 405 associated with the prefix 
string. An OS! network protocol address is 20 bytes 
long for a total of 40 digits. Certain high order digits, 
for example the 16 highest order digits of many ad- 
dresses in the network, may be the same for many 

10 components in a particular OSI network and these 
digit values can be stored as prefix strings in associ- 
ated nodes of the primary database for a single node 
comparison by the address recognition engine 96A. 
Fig. 11 illustrates an exemplary data structure 

15 that can be used as a prefix string 410 in a node 405. 
The prefix string 410 is divided into four words 411. 
The first three words 411 each comprise five digits 
404 and three control bits designated as 
DIG_STR_CNT 412 in bits 0-2 of the word. The con- 

20 trol bits indicate which digits of the word are valid for 
comparison purposes, as will appear. The fourth word 
comprises two digits and an intermediate match poin- 
ter 413. 

The control bits DIG_STR_CNT 412 are used to 
25 make the prefix string 410 flexible so that the prefix 
string 410 can represent a string of from one to 1 7 dig- 
its, according to the address space population of the 
protocol used in a particular network. The 
DIG_STR_CNT bits 412 for a word 411 are interpret- 
so ed by the address recognition engine 96A, as follows: 
DIG_STR_CNT bits 412 equal 000: all five digits are 
valid and further digits in the next word 411 are also 
valid (the control for valid digits in the next word are 
contained in the DIG_STR_CNT bits, 41 2 for the next 
35 word); 

DIG_STR_CNT bits 412 equal 001-101: this is the 
last word of the string and the value of the 
DIG_STR_CNT bits indicates the number of valid dig- 
its in this word; 
40 DIG_STR_CNT bits 412 equal 110: all five digits are 
valid and the first digit of the next word is valid and 
the first digit of the next word is the last digit of the 
string; 

DIG_STR_CNT bits 412 equal 111: all five digits are 
45 valid and the first two digits of the next word are valid 
and the first two digits of the next word are the last 
digits of the string. 

The DIG_STR_CNT bits 412 are set and the dig- 
its of a string are loaded into the prefix string structure 
50 410 of a node 405 to form a string of digits that the 
address recognition engine 96A can compare with 
the corresponding digits of the network address be- 
ing processed. The digit in the address after the string 
is used as an index into node pointers for continuation 
55 of the traversal of the primary database 401. For max- 
imum flexibility, each node 405 of the primary data- 
base 401 is provided with a prefix string data struc- 
ture 410 which is either used or not used depending 
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on the address scheme used in a network. The inter- 
mediate match pointer 413 is used to locate an entry 
in the secondary database 402 for a best match loca- 
tion when an exact match cannot be found, as will be 
described below. 

Each node pointer 407 includes a next node address 
and control fields to control the traversal of the primary 
database 401 by the address recognition engine 96A. An 
example of a node pointer 407 is shown in Fig. 12. An 
IDLCNT field 414 comprises five bits, a LOADJDI field 
415 comprises one bit, a SAVE_RESULT field 416 
comprises one bit, a NEXT_NODE field 417 comprises 
15 bits and a PTR_CTRL field 418 comprises two bits. 

The NEXT_NODE field 417 contains the address 
for the next node 405 in the digit match traversal of 
the primary database 401. 

The SAVE_RESULT field 416 is used in best 
match routing. In certain routing protocols, it is nec- 
essary to find the best match for a network address 
when an exact match cannot be found via the nodes 
405 of the primary database 401. The 
SA\/E_RESULT bit 416 is set in a node pointer 407 
when a best match for an address is valid at the digit 
404 of the address associated with the node 405 
pointed to by the node pointer 407. When the 
SAVE_RESULT bit 41 6 is set, the address recognition 
engine 96A saves the value of the NEXT_NODE field 
417 in an internal register. The stored NEXT_NODE 
value is an address to a next node 405 whose inter- 
mediate match pointer 41 3 is used as a pointer to the 
secondary database 402 should a best match be nec- 
essary (i.e. upon continuation of the traversal of the 
primary database 401, when no exact match is found 
for the address being processed, the address recog- 
nition engine 96Auses the stored NEXT_NODE value 
to access the intermediate match pointer for access 
to the secondary database 402). 

In addition, certain network addresses are divid- 
ed into segments according to, e.g., the IS-IS routing 
protocol. The Internationa! Organization for Standard- 
ization (ISO), for example, defines a hierarchial ad- 
dress structure comprising an initial domain part 
(IDP) and a domain specific part (DSP). The transition 
from the IDP portion to the DSP portion of an ISO for- 
matted address does not follow the tree structure of 
the primary database 401. 

Accordingly, the IDLCNT field 414 and the 
LOADJDI field 41 5 are used to redirect a traversal of 
the primary database 401 at the digit of an ISO ad- 
dress where the IDP portion ends. When the bit of the 
LOADJDI field 415 is set in a node 405, the IDI_CNT 
field 414 will contain the number of digits from the 
current digit to the digit at the end of the IDP portion 
of the address The address recognition engine 96A 
will store the value in the IDLCNT field 414 (IDI 



count) and decrement the IDI count value for each 
subsequent node 405 until the value equals zero. At 
the node where the IDI count equals zero, the ad- 
dress recognition engine 96Awill move to a next node 

5 405 using an address stored in a DSP pointer 407A 
provided at the node 405 (see Fig. 10), The DSP 
pointed 407A points to a node that continues the tra- 
versal for an ISO address. 

When the bit of the LOADJDI field 415 is not set, 

10 and a preselected one of the bits in the IDLCNT field 
414 is set, this will be interpreted as an Area Match 
(AM) bit set Certain protocols, e.g. the DECnet/OSI 
and DECnet/Phase IV protocols, define an area ad- 
dress. When the AM bit is set on a node 405, this in- 

15 dicates that the end of an area address is valid at this 
digit. The continuation of the traversal of the primary 
database 401 after encountering a node 408 having 
a set AM bit will be described below. 

The bits of the PTR_CTRL field 418 provides the 

20 address recognition engine 96A with information on 
the next node 405 pointed to by the NEXT_NODE 
field 417. The bits of the PTR_CTRLfield418 are in- 
terpreted, as follows: 

PTR_CTRL bits equal 00: the next node does not con- 
25 tain a prefix string; as described above, each node is pro- 
vided with a prefix string structure, when the PTR_CTRL 
bits are 00, the prefix string structure of the next node 
is not used and the 00 bits tell the address recognition 
engine 96Ato ignore the structure in the next node; 
30 PTR_CTRL bits equal 01: the next node contains a 
prefix string, accordingly, the address recognition en- 
gine 96A will compare the corresponding digits of the 
address being processed to the valid digits of the 
string, as indicated by the DIG STR_CNT bits 412 of 
35 the prefix string 410; 

PTR_CTRL bits equal 10: the next node is a ''pad- 
ding" entry, this tells the address recognition engine 
96A to reuse the current node 405 because padding 
digits exist in the address, the padding digits are strip- 
40 ped from the address and the traversal continues^, 
the NEXT_NODE field 417 is ignored; 
PTR_CTRL bits equal 11: the pointer indicates a look- 
up-fail, the pointer indicates that the intermediate 
match pointer saved from the node where the 
45 SAVE_RESULT bit was set should now be used to ac- 
cess the secondary database, the NEXT_NODE field 
417 is ignored. 

When a termination node 405B is reached, the 
address recognition engine 96Awill access the sec- 
50 ondary database 402 with the appropriate look-up 
match pointer 409. The address recognition engine 
96A will retrieve information from a corresponding 
secondary database entry according to control bits of 
the look-up database specifier indicated by the look- 
55 up type field 403B of the respective request, as will 



^ The IDI field of the IDP portion of an OSI standard address is right justified and padded to fill the fixed length of 
the field. The padding digits are looped back to the cun-ent node 305 using the padding pointers. 
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appear. If the PTR_CTRL bits of the node pointer 405 
to the termination node 405B indicate that the ternnin- 
ation node contains a string, then the address recog- 
nition engine 96Amust compare the remaining digits 
of an address being processed with the string. If a 
match occurs, the corresponding look-up match poin- 
ter 409 of the termination node 405 is used to access 
the secondary database 402. If there Is no match or 
if there are less digits remaining in the address than 
in the string, then the intermediate match pointer 
saved from the node 405 where the SAVE_RESULT 
bit was set is used to access the secondary database 
402. 

Referring now to Fig. 13, there is illustrated an ex- 
emplary format for a secondary database entry 500. 
There are three types of secondary database entries 
500: a common block 501, a path split block 502 and 
an adjacency block 503. Each common block 501 is 
linked to a path split block 502. There are an equal 
number of common, path split and adjacency blocks 
501, 502, 503 in the secondary database 402. There 
is no direct relationship between each linked common 
block/path split block and the adjacency blocks. Each 
of the common and adjacency blocks 501, 502 con- 
tains information to be returned by the address rec- 
ognition engine 96A as a response to the request/re- 
sponse RAM 96B. 

Each common block 501 is eight words long. The 
first three words 501 A are used to maintain ageing 
and learning information required when the destina- 
tion of a data packet is reached using a bridge, as will 
be described below. The remaining five words 501 B 
are uncommitted and are used to store any informa- 
tion that may be required for return in a response, as 
for example routing information for OS I or DECnet 
network protocols, '^tc. Each of the look-up match 
409 and intermediate look-up 413 pointers of the pri- 
mary database 401 index a corresponding common 
block 501. 

Each path split block 502 is linked to a respective 
common block 501 and comprises a group of four 
pointers used to select an adjacency block 503 for use 
in a current response. 

Each adjacency block 503 is four words long. The 
words of each adjacency block 503 also contain infor- 
mation that may be required in a response. Succes- 
sive look-up's to the same common block 501 of the 
secondary database 402 may each return informa- 
tion from a different adjacency block 503 depending 
upon the path splitting operation. 

Each path split block 502 includes a NUM_PATHS 
field 504 comprising two bits, a LAST_PATH field 
505 comprising two bits and four adjacency block poin- 
ters 506, each comprising 15 bits designated 
ADJ_PTR_0 to ADJ_PTR_3, respectively. Each adja- 
cency block pointer 506 points to a respective adjacency 
block 503. The bits of the NUM_PATHS field 504 are 
interpreted by the address recognition engine 96A, as 



follows: 

NUM_PATHS bits equal 00: one adjacency block only 
is accessed through the path split block 502, as indi- 
cated by ADJ_PTR_0; 
5 NUM_PATHS bits equal 01 : one of two different ad- 
jacency blocks is accessed through the path split 
block 502, as indicated by either ADJ_PTR_0 or 
ADJ_PTR_1; 

NUM__PATHS bits equal 10: one of three different ad- 
10 jacency blocks is accessed through the path split 
block 502, as indicated by one of ADJ_PTR_0 to 
ADJ_PTR_2; 

NUM_PATHS bits equal 11: one of four different ad- 
jacency blocks is accessed through the path split 

15 block 502, as indicated by one of ADJ_PTR_0 to 
ADJ_PTR_3. 

The LAST_PATH field 505 indicates the number 
of the adjacency block pointer 506 to use during a cur- 
rent retrieval of information from the secondary data- 

20 base 402 for a response. The bits of the LAST_PATH 
field 505 are interpreted by the address recognition 
engine 96A, as follows: 

l_AST_PATH bits equal 00: utilize AD J_PTR_0 for the 
current response; 
25 LAST_PATH bits equal 01 : utilize ADJ_PTR_1 for the 
current response; 

LAST_PATH bits equal 10: utilize ADJ_PTR_2 for the 
current response; 

LAST_PATH bits equal 11: utilize ADJ_PTR_3 for the 

30 current response. 

Each time the address recognition engine 96A 
enters a path split block 502, it increments the 
LAST_PATH field 505. If the value of the bits in the 
LAST_PATH field 505 exceeds the value of the bits 

35 in the NUM_PATHS field 504 of the path split block 
502, then the LAST_PATH field 505 is set to zero. Thus, 
the value of the bits in the LAST_PATH field 505 cycles 
from 0 to the value of the bits in the NUM__PATHS field 
504 of the path split block 502. 

40 The path splitting operation provided by the path 

splitting block 502 provides automatic control of rout- 
ing information changes that may be desired in a par- 
ticular routing protocol on successive transmissions 
of data packets to a particular network address. The 

45 NUM_PATHS and LAST_PATH fields 504, 505 can be 
utilized to set a number of different adjacency blocks 
to be accessed on successive reads of a particular 
common block 501 and to control which adjacency 
block is read during a current common block read. 

50 Referring now to Fig. 14, there is shown an ex- 

emplary format for a look-up database specifier 600. 
As discussed above, the address recognition engine 
96A maintains a table 94A of look-up database spe- 
cifiers 600, e.g. 24 look-up database specifiers 600. 

55 In processing a specific request, the address recog- 
nition engine 96A proceeds to traverse the primary 
database 401 and retrieve information from the sec- 
ondary database 402 according to control bits set in 



15 



27 



EP 0 556 148 A1 



28 



a particular look-up database specifier 600 indicated 
by the processor 90A, 90B in the look-up type field 
403B of the request 403 (see Fig. 8). 

As described above, the processor 90A, 90B 
analyzes the protocol type information contained in 
the header of a data packet and uses that information 
to select an appropriate identifier for a corresponding 
database specif ier from its table 93A, 938. The proc- 
essor 90A, 9GB then writes the selected identifier into 
the index field 403B of a request 403. This scheme 
provides an interlock between the processor 90A, 
908 and the address recognition engine 96A that af- 
fords maximum flexibility in the structure of the data- 
base 94. 

For example, the multiple root node arrangement 
for the primary database 401 permits maximum flex- 
ibility to accommodate the various address lengths 
and formats of diffent network protocols. The appro- 
priate root node index for each protocol can be spe- 
cified in a corresponding database specifier. The 
processor 90A, 908 can readily correlate the protocol 
type information transmitted in each header through 
the cross reference table 93A, 938. 

Moreover, different protocols require different ad- 
dress formats and other items, such as protocol 
class, that may be stored in the common block 501 
and related adjacency blocks 503 of the secondary 
database entry 500 pointed to in the processing of a 
particular request. The look-up database specifiers 
provide a mechanism for controlling what information 
is returned in a response. 

Each look-up database specifier 600 comprises 
six fields: an argument length field (ARG_LENGTH) 
601 comprising 6 bits, a root database TRIE field 
(ROOT_TRIE) 602 comprising five bits, an area 
match count field (AM_CNT) 603 comprising six bits, an 
area match root database TRIE field 604 {AM_TRIE) 
comprising five bits, a look-up control bits field 605 in- 
cluding a preselected number of look-up control bits, 
and a secondary database mask (SD8_MASK) 606 
comprising 31 bits. 

The argument length field 601 indicates the num- 
ber of digits in the address portion 403Aof a particular 
request 403 (see Fig. 8). As discussed above, the net- 
work addresses written as requests into the re- 
quest/response RAM 968 can be fixed length or vary 
in length, depending upon the network protocol asso- 
ciated with each particular address. 

The root database TRIE field 602 specifies which 
root transition node is to be used in the primary data- 
base 401. The primary database 401 can be imple- 
mented with a plurality of roots, each used to com- 
mence a search for a secondary database look-up 
match pointer 409. Thus, the number set in the ROOT 
TRIE field 602 is used by the address recognition en- 
gine 96Ato determine at which root the search should 
begin. 

The area match count field 603 indicates the 



number of remaining digits beyond the digit indicated 
by a set AM bit to complete an area, as described 
above, for an area transition within the primary data- 
base 401. The area match root TRIE field 604 indi- 

5 cates the root node 405 of the primary database 401 
to be used for the remaining area-match-count digits 
of the address. 

If the AM bit is set in a node pointer 407 and the 
number of digits remaining in an address being proc- 

10 essed equals the value in the area match count field 

603 of the look-up database specifier 600 indicated 
in the request 403, then a transition is made to the 
root node specified by the area match root TRIE field 

604 of that look-up database specifier 600. The next 
15 digit of the address being processed Is used for 

matching in the specified root node. If the number of 
remaining digits is not equal to the area match count 
value or if the AM bit is not set In a node pointer 407, 
then the next digit is looked up in the node pointed to 

20 by NEXT_NODE field 417 of the node pointer 407. 

The look-up control bits field 605 can include va- 
rious bits used to control the operation of the address 
recognition engine 96A during a look-up operation. 
For example, a look-up disable bit can be provided to 

25 disable a look-up type specified by the associated 
look-up database specifier 600 when set, an error is 
returned if the associated look-up database specifier 
600 is indicated in the look-up type field 403B of a re- 
quest. 

30 The address recognition engine of the present In- 

vention is adapted to support both routing and bridg- 
ing protocols. As described above, each common 
block 501 Includes three words 501A reserved for 
ageing and learning information necessary for the im- 

35 plementation of a bridging protocol. A port learning 
and ageing bit is included in the look-up control bits 
field 605 to indicate to the address recognition engine 
96Athat a particular network destination address re- 
quires a bridging operation to transfer the respective 

40 data packet. When the port learning and ageing bit is 
set in a look-up database specifier 600, the following 
learning and ageing functions are performed by the 
address recognition engine 96A. 

The address recognition engine 96A reads the 

45 first word 501A of the common block 501 for an up- 
date mask 508 comprising 16 bits. Each bit of the up- 
date mask 508 corresponds to, e.g., one of the ports 
in the line card 74A, 748 that can be a source port in 
a bridge. For each port whose corresponding bit is set 

50 in the mask 508, a learning operation is performed. 
The processor 90A, 908 will include a bit number in 
each request to specify a particular bit in the mask 
508 relating to a bridging address. The address rec- 
ognition engine 96A will determine If the bit for the 

55 port number specified by the processor 90A, 908 in 
the request is set in the mask 508. If the specified bit 
is not set, learning is not performed by the address 
recognition engine 96A for that port. However, a timer 
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override bit 508 is provided in the first word 501A, 
When each of the tinner override and port learning 
and ageing bits are set, the address recognition en- 
gine 96A will perform the ageing function in respect 
of the common block 501 . 

Upon entry to the common block 501 for a bridg- 
ing address, the address recognition engine 96A 
clears a bridging access timer 510 in the second word 
501 A to zero and sets a timer alive bit 511 , also in the 
second word 501 A. The timer field comprises 20 bits. 
As a background operation, the address recognition 
engine 96A polls each common block 501 having a set 
timer alive bit 511, e.g. once each second, and incre- 
ments the value in the timer field 510. 

The address recognition engine 96A maintains an 
ageing time-out value which is compared to the incre- 
mented value in the timerf ield 510. If the incremented 
value in the timer field 51 0 is larger than the ageing 
time-out value, then the timer alive bit 511 is cleared 
to indicate that the bridging Information in the corre- 
sponding common block 501 has aged out, as under- 
stood by the bridging protocol. 

The second word 501 A also includes a timer dis- 
able bit 51 2. When the timer disable bit 51 2 is set, the 
timer field 510 is not incremented. The timer disable 
bit 512 is set in any common block 501 for which age- 
ing is not to be performed. If both the timer disable bit 
512 and timer alive bit ill are set, this maintains the 
common block 501 as "permanently alive". 

The third word 501Aof the common block 501 in- 
cludes a port number field 513 and a last seen field 
514 used for source port learning. When the port 
learning and ageing bit is set and the learning oper- 
ation is being performed (as indicated by the appro- 
priate bit in the update mask 508), the address rec- 
ognition engine 96A will write the source port number 
for a data packet into the port number: field 513. The 
source port number is also written into the last seen 
field 514, whether or not the learning operation is be- 
ing performed. 

The look-up control bits field 605 can also include 
an enable adjacency set-on-access bit to indicate to 
the address recognition engine QSAthat a set-on-ac- 
cess (A_SOA) bit 515 (provided in each adjacency 
block 503, see Fig. 1 3) be set when the address rec- 
ognition engine 96A reads an adjacency block 503. 
The set-on-access bit 515 supports the address re- 
solution protocol cache requirements of the IP net- 
work protocol. The cache requirements of the IP pro- 
tocol car. be implemented in the processor 90A, 90B 
of the line card 74A, 74B. A set A_SOA bit 515 indi- 
cates to the processor 90A, 90B that the respective 
adjacency block 503 has been used in a routing op- 
eration. 

The secondary database mask (SDB_MASK) 
606 of each look-up database specifier 600 is used to 
select which bytes of data stored in the five longwords 
501 B of a common block 501 and the four longwords 



of a related adjacency block 503 are to be returned to 
the processor 90A, 90B in a particular response. 

The first 1 9 bits of the mask 606 determine which 
bytes of the common block 501 are returned. Each 

5 byte of the common blocks 501 corresponds to one 
of the 19 bits. If the corresponding bit of the mask 606 
is set, the byte is returned in the response. Similarly, 
the next 12 bits are used to determine which bytes of 
the adjacency block 503 are returned in the re- 

10 sponse, as a function of which of the 12 bits are set. 
If all of the adjacency bits of the mask 606 are zero 
and the enable adjacency set-on-access bit of the 
look-up control bits field 605 is not set, then the path 
split adjacency block pointers 506 are not used and 

15 the LAST_PATH field 505 is not incremented. 

The various control bits of the prefix string data 
structures 410, the node pointers 407, the path split 
blocks 502 and the look-up database specifiers 600 
provide maximum flexibility in the control of the tra- 

20 versal of the primary database 401 and the retrieval 
of routing or bridging information from the secondary 
database 402. The control bit arrangement of the ad- 
dress recognition engine 96A builds in device compa- 
tibility to accommodate the varying requirements of 

25 dissimilar routing and bridging protocols in a single 
memory structure that can provide a centralized re- 
source to several components performing bridging or 
routing operations in a computer network. 

30 

Claims 

1, A computer system, which comprises: 

a line card adapted to receive and transmit 
35 data transmissions to and from a data transmis- 

sion lire; 

an address recognition engine including a 
network information lookup database; 

the lookup database comprising a plurality 
40 of entries, each one of the plurality of entries con- 

taining network information, the network infor- 
mation relating to computer network addresses 
contained in the data transmissions; 

a backplane bus coupling the line card and 
45 the address recognition engine to one another; 

the line card including a first table of iden- 
tifiers for database specifiers, each identifier re- 
lating to a protocol type identified in the data 
transmissions received at the line card; 
50 the line card operating to transmit to the 

address recognition engine, via the backplane 
bus, requests for network information relating to 
the data transmissions received at the line card, 
the requests each containing a network address 
55 and an identifier for a database specifier corre- 

sponding to the protocol type for a respective 
data transmission; 

the address recognition engine including a 

17 
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second table of database specifiers indexed by 
the identifiers; 

the address recognition engine operating 
to use the identifier of each request to select a da- 
tabase specif ier from the second table and to use 5 
the network address of the request as a lookup 
index to the lookup database for access to and re- 
trieval of a corresponding one of the net-work in- 
formation entries as a response; 

wherein each database specifier contains io 
control information for control of the address rec- 
ognition engine during the access to and retrieval 
of the corresponding one of the entries; 

the address recognition engine operating 
to affect the transmission of the response to the i5 
line card via the backplane bus for use by the line 
card. 
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2. The computer system of claim 1 wherein the net- 
work information lookup database comprises a 
primary database and a secondary database, the 
plurality of network information entries being ar- 
ranged in the secondary database, the primary 
database comprising a plurality of linked nodes 
for matching to preselected portions of a network 25 
address contained in a request so that a network 
address input to the primary database traverses 
the linked nodes according to matches among 
linked nodes to locate a secondary database 
pointer to one of the entries of the secondary da- 30 
tabase, the address recognition engine using 
each network address as an input to the primary 
database and using the located secondary data- 
base pointer to access and retrieve the corre- 
sponding one of the network information entries 35 
from the secondary database under the control of 
the control information contained in the selected , 
database specifier. 

3. The computer system of claim 2, wherein the line 40 
card receives and transmits data transmissions in 
the form of data packets, each one of the data 
packets including network address information 
comprising an n-bit field of the respective one of 
the data packets and protocol type information, 45 
each network address of a request comprising 
one of the n-bitf ields containing network address 
information; and wherein the address recognition 
engine segments each n-bit request into a plural- 
ity of m-bit digits for traversal through the primary so 
database, each m-bit digit having one of 2m dis- 
tinct values, further wherein the plurality of linked 
nodes includes at least one set of transition nodes 
and a set of termination nodes linked to each one 
of the at least one set of transition nodes, each of 55 
the at least one set of transition nodes being 
linked to a root node and each of the at least one 
root node and each node of the at least one set 
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of transition nodes includes 2m node pointers for 
linking to subsequent nodes, each one of the 
node pointers of one of the root and transition 
nodes corresponds to one of the 2m distinct val- 
ues and points to a subsequent one of one of the 
at least one set of transition nodes and the linked 
set of termination nodes, each one of the termin- 
ation nodes includes 2m secondary database 
pointers, each one of the secondary database 
pointers of one of the termination nodes corre- 
sponds to one of the 2m distinct values and points 
to one of the network information entries of the 
secondary database, the digits of each request 
being matched, one at a time, in a preselected se- 
quence of digits, to a corresponding sequence of 
linked node pointers of a root node and subse- 
quent transition nodes to traverse the primary da- 
tabase to one of the termination nodes. 

4. The computer system of claim 3 wherein the con- 
trol information of each one of the database spe- 
cif iers includes root node information to indicate 
to the address recognition engine which root 
node to commence a traversal of the primary da- 
tabase , wherein the control information of each 
one of the database specifiers includes an area 
match information field, the area match informa- 
tion field representing a set state and a clear 
state, the set state indicating to the address rec- 
ognition engine that the traversal of the primary 
database is to be redirected at a preselected one 
of the digits of a network address and the clear 
state indicating to the address recognition engine 
that the traversal of the primary database is to 
continue without redirection. 

5. The computer system of claim 1, wherein the con- 
trol information of each one of the database spe- 
cifiers includes an area match count field and an 
area match rootf ield. each area match countf ield 
indicates to the address recognition engine the 
preselected one of the digits of a request at which 
a redirection of traversal of the primary database 
is to occur when area match information at any 
one digit of the network address is in the set state 
and each area match root field indicates to the 
address recognition engine a preselected node of 
the primary database where the traversal of the 
primary database is to continue for remaining 
subsequent digits of the request. 



6. The computer system of claim 1 wherein the con- 
trol information of each one of the database spe- 
cifiers includes an information mask to indicate to 
the address recognition engine preselected por- 
tions of the network information contained in the 
respective one of the entries, for use in the re- 
sponse , wherein each one of the entries com- 
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prises a bridging information field; and wherein 
the control information of each one of the data- 
base specifiers includes a port learning and age- 
ing field, the port learning and ageing field being 
in one of a set state and a clear state, and wherein 5 
the address recognition engine is controlled to 
perform a bridging operation to read and write 
bridging information from and to the bridging in- 
formation field when the port learning and ageing 
field of a selected database specifier is in the set io 
state. 

7. The computer system of claim 1 further compris- 
ing a request /response memory coupled to the 
address recognition engine for storage of re- 15 
quests from the line card and corresponding re- 
sponses from the lookup database, wherein the 
request/response memory comprises a plurality 

of entries, each of the entries including a request 
storage memory space for storing a request and 20 
a response storage memory space for storing a 
corresponding response further, wherein the re- 
quest storage memory space of each one of the 
entries includes a first preselected space for stor- 
age of ownership information; the ownership in- 25 
formation of the first preselected space indicat- 
ing whether a request stored in the respective re- 
quest storage memory space is valid for use by 
the address recognition engine and the owner- 
ship information of the second preselected space 30 
indicating whether a response stored in the re- 
spective response memory space is valid for use 
by the line card. 

8. The computer system of claim 1 wherein the line 35 
card operates to transmit each request by writing 
each request in the request storage memory 
space of a preselected one of the entries and si- 
multaneously writing ownership information in 

the respective first preselected space to indicate 40 
that the corresponding request is valid, wherein 
the address recognition engine polls and read 
each request storage memory space and uses 
each valid request to access the network infor- 
mation lookup database for a corresponding re- 45 
sponse, the address recognition engine writing 
ownership information in the respective first pre- 
selected space upon reading a request, to indi- 
cate that the corresponding request is now not 
valid, and storing each response in the response 50 
storage memory space of the preselected one of 
the entries storing the respective request and 
writing ownership information in the respective 
second preselected space to indicate that the 
corresponding response is valid. 55 

9. The computer system of claim 8, wherein each 
first preselected space stores ownership infor- 



mation comprising OWN_lD information and 
REQJD information; 

the OWNJD information representing one 
of a set state and a clear state, the set state indi- 
cating to the address recognition engine that a re- 
quest stored in the respective request memory 
space is valid for use by the address recognition 
engine and the clear state indicating to the ad- 
dress recognition engine that a request stored in 
the respective request memory space is not valid 
for use by the address recognition engine; 

the REQJD information representing one 
of a set state and a clear state, the state of the 
REQJD information being used by the address 
recognition engine to determine ownership infor- 
mation for writing in the second preselected 
space, wherein the line card writes ownership in- 
formation in a respective first preselected space 
by setting the OWNJD information and writing 
REQJD information in a state that is opposite to 
the state of the REQJD information prior to the 
writing of ownership by the line card, further 
wherein each second preselected space stores 
ownership Information comprising RSPJD infor- 
mation; the RSPJD information representing 
one of a set state and a clear state, the state of 
the RSPJD information written by the address 
recognition engine upon storing a response, be- 
ing a state that matches the state of the REQJD 
information when the address recognition engine 
polls and reads the respective valid request. 

10. The computer system of claim 9 wherein the line 
card reads the response memory storage space 
of each one of the preselected entries containing 
a request written by the line card, the response 
being valid for use by the line card when the state 
of the RSPJD information in the second prese- 
lected space of the respective response memory 
space matches the state of the REQJD informa- 
tion written by the line card upon writing the cor- 
responding request. 
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